Skip to content

[NV] Kimi-K2.6 NVFP4 B300 disagg multinode dynamo-vllm benchmarks / [NV] Kimi-K2.6 NVFP4 B300 分离式多节点 dynamo-vllm 基准测试#2181

Open
RohitNagraj wants to merge 8 commits into
mainfrom
kimik2.6-fp4-b300-dynamo-vllm
Open

[NV] Kimi-K2.6 NVFP4 B300 disagg multinode dynamo-vllm benchmarks / [NV] Kimi-K2.6 NVFP4 B300 分离式多节点 dynamo-vllm 基准测试#2181
RohitNagraj wants to merge 8 commits into
mainfrom
kimik2.6-fp4-b300-dynamo-vllm

Conversation

@RohitNagraj

Copy link
Copy Markdown
Collaborator

Description

Adds Kimi-K2.6 NVFP4 disaggregated multinode dynamo-vllm coverage on B300, parallel to the existing GB300 Kimi entries (#1861).

  • New kimik2.6-fp4-b300-dynamo-vllm config in configs/nvidia-master.yaml wiring 8k/1k fixed-seq-len sweeps to seven recipes under recipes/vllm/kimi-k2.6-fp4/8k1k/ (dep4-dep8, dep4-tp4, dep4-tp8 topologies incl. FlashInfer-autotune variants), conc 1-4096.
  • New Slurm recipe YAMLs under benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k2.6-fp4/8k1k/.
  • runners/launch_b300-nv.sh maps kimik2.6 + fp4 to /scratch/models/Kimi-K2.6-NVFP4, copies the recipes into a pinned srt-slurm checkout on dynamo-vllm runs, and passes --no-preflight to srtctl apply since the model path lives on compute-node-local NVMe.
  • perf-changelog.yaml documents the new config key.

中文说明

在 B300 上新增 Kimi-K2.6 NVFP4 分离式多节点 dynamo-vllm 基准测试,与现有 GB300 Kimi 配置(#1861)对齐。

  • configs/nvidia-master.yaml 中新增 kimik2.6-fp4-b300-dynamo-vllm 配置,将 8k/1k 固定序列长度扫描接入 recipes/vllm/kimi-k2.6-fp4/8k1k/ 下的七个配方(dep4-dep8、dep4-tp4、dep4-tp8 拓扑,含 FlashInfer autotune 变体),并发 1-4096。
  • benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k2.6-fp4/8k1k/ 下新增 Slurm 配方 YAML。
  • runners/launch_b300-nv.shkimik2.6 + fp4 映射到 /scratch/models/Kimi-K2.6-NVFP4,在 dynamo-vllm 运行时将配方复制到固定 commit 的 srt-slurm 检出中,并为 srtctl apply 传入 --no-preflight(模型路径位于计算节点本地 NVMe)。
  • perf-changelog.yaml 记录新的配置键。

Related Issue

N/A

Type of Change

  • Bug fix
  • New feature
  • Configuration change
  • Documentation update
  • Other (please describe)

Checklist

  • I have tested my changes locally
  • I have updated documentation if necessary
  • If I changed a container image or config, I have already updated perf-changelog.yaml
    • New perf-changelog.yaml entries are appended to the end of the file (the file is chronological: oldest at top, newest at bottom)
  • Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /reuse-sweep-run on this PR — do this only once there is a final full sweep that is all green with evals passing, since after this comment the sweep label will no longer automatically kick off new sweeps (remove and re-add the label to force one)

Add kimik2.6-fp4-b300-dynamo-vllm to configs/nvidia-master.yaml with seven
8k1k disaggregated topologies, stage the vLLM recipes under
benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k2.6-fp4/8k1k/, wire the
model path and a pinned srt-slurm checkout into runners/launch_b300-nv.sh
(with --no-preflight for the compute-node-local model path), and append the
perf-changelog entry.

中文:新增 Kimi-K2.6 NVFP4 B300 分离式多节点 dynamo-vllm 基准测试:在
configs/nvidia-master.yaml 中新增 kimik2.6-fp4-b300-dynamo-vllm(七个 8k1k
分离式拓扑),在 benchmarks/multi_node/srt-slurm-recipes/vllm/kimi-k2.6-fp4/8k1k/
下新增 vLLM 配方文件,在 runners/launch_b300-nv.sh 中接入模型路径与固定
commit 的 srt-slurm 检出(模型路径仅存在于计算节点本地,故使用
--no-preflight),并追加 perf-changelog 记录。
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

1 similar comment
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs


感谢你的贡献!请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人,你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板,包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have

如需进行 PR 验证,请为此 PR 添加 full-sweep-fail-fast 标签(强烈推荐)— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动(flake),重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

中文:将 perf-changelog 中的 pr-link 更新为 #2181
…entry

Main now requires kv-p2p-transfer on disagg entries (PR #2096); set nixl to
match the recipes' NixlConnector and add the dynamo-router metadata, matching
the other dynamo-vllm disagg entries.

中文:适配主分支新增的校验规则(PR #2096):为 kimik2.6 B300 分离式配置补充
kv-p2p-transfer: nixl(与配方中的 NixlConnector 一致)及 dynamo-router 元数据,
与其他 dynamo-vllm 分离式配置保持一致。
A shared literal engine_id across independent prefill workers collides in
vLLM's decode-side NIXL handshake cache (keyed on engine_id alone), so
multi-prefill topologies could silently read KV from the wrong prefill
host. Omit the field so vLLM auto-generates a unique per-process id,
matching every other disagg recipe in the tree.

中文:移除 kimik2.6 B300 配方中硬编码的 NixlConnector engine_id。多个独立
预填充 worker 共用同一 engine_id 时,会在 vLLM 解码侧的 NIXL 握手缓存
(仅以 engine_id 为键)中发生冲突,多预填充拓扑可能静默地从错误的预填充
节点读取 KV。省略该字段后 vLLM 会为每个进程自动生成唯一 id,与仓库中其他
分离式配方保持一致。
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

srt-slurm at the pinned commit passes --device-ids to vLLM workers by
default, but that flag only exists in vLLM builds newer than v0.22.0
(vllm-project/vllm#45026, merged 2026-06-20), so every worker exited with
"unrecognized arguments". Set the schema's set_cuda_visible_devices
fallback so srtctl binds GPUs via CUDA_VISIBLE_DEVICES instead.

中文:srt-slurm 固定 commit 默认向 vLLM worker 传递 --device-ids,但该参数
仅存在于比 v0.22.0 更新的 vLLM 版本(vllm-project/vllm#45026,2026-06-20
合入),导致所有 worker 以 "unrecognized arguments" 退出。改用 schema 提供的
set_cuda_visible_devices 回退,使 srtctl 通过 CUDA_VISIBLE_DEVICES 绑定 GPU。
@github-actions

Copy link
Copy Markdown
Contributor

3 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

Set explicit UCX knobs for the NIXL P->D KV transfers on every worker:
single-rail RMA/rendezvous, put_zcopy rendezvous scheme, memtype
cache/whole-registration off (safe with cuMem-backed allocators), and
CUDA-IPC-over-MNNVL off. UCX_NET_DEVICES stays cluster-provided.

中文:为 kimik2.6 B300 分离式配方补充显式 UCX 传输调优:NIXL P->D KV 传输
使用单 rail RMA/rendezvous、put_zcopy rendezvous 方案、关闭 memtype 缓存与
整块注册(对 cuMem 分配器更安全)、关闭 MNNVL 上的 CUDA-IPC。
UCX_NET_DEVICES 仍由集群环境提供。
Resolve perf-changelog.yaml: keep main's full entry list with this
branch's kimik2.6-fp4-b300-dynamo-vllm entry re-appended at the end.

中文:合并 origin/main;perf-changelog.yaml 冲突按规则解决——保留 main 的
完整条目列表,并将本分支的 kimik2.6-fp4-b300-dynamo-vllm 条目重新追加到末尾。
@github-actions

Copy link
Copy Markdown
Contributor

4 similar comments
@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@github-actions

Copy link
Copy Markdown
Contributor

@xinli-sw

Copy link
Copy Markdown
Collaborator

/reuse-sweep-run

@Ankur-singh

Copy link
Copy Markdown
Collaborator

As a PR reviewer and CODEOWNER, I have reviewed this and have:

  • Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
  • Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
  • Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this: Run Sweep 29533443307, attempt 5.
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this: Run Sweep 29533443307, attempt 5.
  • Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
  • For agentic workloads: verified that speculative-decoding configs (EAGLE / MTP / draft models) run with simulated synthetic acceptance, with the acceptance-length value taken from the committed golden AL curve in golden_al_distribution/ for that model, thinking mode, and draft length. A submission may choose any supported draft length, but it may not substitute a different acceptance target.
  • Verified that the model architecture isn't changed with benchmark hacks like using --hf-overrides to skipping indexer for every x layers on models that don't natively support this. As a general rule, we won't accept optimizations that reduces the number of model architecture FLOPs. Anything that makes that same computation run faster is fair game; FLOPs at lower precisions is fine, given that the config passes private evals. As an general north star princple, we should only use optimizations which is used in production by customers that care about accuracy
  • If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet as supported by vLLM/SGLang community maintainers
  • If an company claims that they support vLLM/SGLang as first class upstream in-tree LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
  • Verified that every single-node vLLM/SGLang recipe in this PR is documented in the official vLLM recipes and/or the SGLang cookbook:
    • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang repo and verified that it is MERGED before this InferenceX PR merges. An opened, draft, or closed-without-merge upstream PR does not satisfy this requirement. If the matching recipe was already published, I linked the published recipe/cookbook page in the additional detail section below.
  • Verified that this PR does not patch the inference engine or serving stack — the pinned image must run as shipped. This covers .patch files / git apply / patch, inline patches embedded in benchmark scripts (e.g. a python3/sed heredoc that rewrites installed engine sources before serving), in-place edits of site-packages, monkey-patching, overwriting container files, and installing forked/rebuilt engine wheels on top of the pinned image. The only exception is a patch covered by a filled-out waiver at docs/waiver/<PR_NUMBER>.md — named after the PR that introduces the patch and filed in that same PR, stating what is patched, why the unmodified upstream image cannot run this benchmark, the upstream PR/issue link, and the removal plan — which I have linked below in the additional detail section.
  • If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.

Additional detail section:

  • Validation evidence: exact PR head 8e136914e8e16a7592b4df5cf6a691034b65626c; Run Sweep 29533443307, attempt 5 completed successfully with all seven applicable multi-node 8k/1k benchmark jobs, all seven applicable multi-node eval jobs, collect-results, collect-evals, compare-results, and success-rate processing passing.
  • Eval evidence: artifact eval_results_all (8478057668) contains seven Kimi-K2.6 GSM8K scores from 0.96816 to 0.97119, above the pinned-head 0.90 threshold, using vllm/vllm-openai:v0.22.0.
  • Scope: this is exclusively a fixed-sequence multi-node/disaggregated submission. It does not change speculative decoding or AgentX workloads, so the chat-template and golden-acceptance items are not applicable.
  • Upstream recipe: vLLM recipes PR #634 is merged, and the published recipe is available at models/moonshotai/Kimi-K2.6.yaml.

Signed: Ankur-singh

@Klaud-Cold

Copy link
Copy Markdown
Collaborator

✅✅✅ Verdict: PASS ✅✅✅

✅ Check 0 (CODEOWNER): PASS — Ankur-singh is a named owner of configs/nvidia-master.yaml; the other changed paths carry only the * catch-all, which any recognized CODEOWNER satisfies.
✅ Check 1 (sweep on in-PR commit): PASS — the PR head 8e13691 itself carries all seven multi-node 8k1k / and all seven multi-node eval / check-runs with conclusion success (executed, not skipped) from run 29533443307; the single-node */ / eval / lanes are skipped only because this PR has no single-node configs.
✅ Check 2 (eval accuracy): PASS — artifact eval_results_all from that run has 7 Kimi-K2.6 GSM8K scores from 0.96816 to 0.97119, above the 0.90 threshold (utils/evals/thresholds.yaml), run on vllm/vllm-openai:v0.22.0 — the same image as this PR's config.
➖ Check 3 (recipe link): N/A — disaggregated/multi-node submission (benchmarks/multi_node/**, multinode: true, disagg: true, framework dynamo-vllm); the recipe-link requirement applies to single-node recipes only. Informational: the sign-off nonetheless links vllm-project/recipes#634, verified MERGED 2026-07-15.
✅ Check 4 (reuse command): PASS — /reuse-sweep-run posted by xinli-sw (COLLABORATOR).
✅ Check 5 (latest checklist template): PASS — every current-template item is present; the two unchecked items (spec-decode chat template, agentic golden AL) are explained as inapplicable in the additional detail section, which matches the diff (no spec-decode anywhere).
✅ Check 6 (upstream image / engine-first): PASS — image is upstream vllm/vllm-openai:v0.22.0; the engine is upstream vLLM (Dynamo is the disagg orchestrator, not a different engine), and this is the first kimik2.6 entry in the master configs, so the vLLM-engine submission lands before any additional framework.
✅ Check 7 (no architecture hacks): PASS — no --hf-overrides / model-config edits; flags are precision, kernel-backend, and fusion choices (kv-cache fp8, FLASHINFER_MLA, compilation-config fusion passes) with evals passing.
➖ Check 8 (spec-decode chat template): N/A — no speculative-decoding changes in this PR.
✅ Check 9 (no engine patches): PASS — no .patch/git apply/heredoc rewrites or forked engine wheels; the launcher change only pins the srt-slurm harness checkout, copies recipe YAMLs into it, and passes --no-preflight (harness-side, node-local model path).
➖ Check 10 (agentic golden AL): N/A — no agentic speculative-decoding changes.

@functionstackx functionstackx left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adibarra has quiestion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

5 participants